Activity reporting in a collaboration system

ABSTRACT

A processing device used to support communications between users of the collaboration system is operative to capture occurrence of at least one event defined in accordance with a project plan. Information regarding each such captured event is stored and an activity report based at least in part upon the stored event information is provided by the processing device to at least one other user of the collaboration system. Report annotations may be associated with the activity report. A controller within the collaboration system is employed to route the activity report (and any associated annotations) to other users of the collaboration system. The recipients of the activity report may submit their own annotations to the controller for association with the activity report. Furthermore, the controller may operate to aggregate the activity report with other activity reports.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present invention is related to co-pending applications havingattorney docket numbers 33836.00.0119 and 33836.00.0141, filed on evendate herewith.

FIELD OF THE INVENTION

The present invention relates to techniques for fostering acollaborative environment and, in particular, to a collaboration systemthat provides improved capture, distribution and maintenance ofcommunications and contexts therefore.

BACKGROUND OF THE INVENTION

With the advent of more powerful communication technologies, the use ofcross-border collaborative project teams has increased. For example, itis not uncommon in the software development industry to have teams ofdevelopers and management spread across the globe. While suchcollaborative project teams typically enjoy the benefit of being able todraw upon efficient resources, the remoteness between team members cangive rise to significant challenges that may significantly undercut, orentirely overwhelm, the efficiencies gained.

For example, where the project at hand comprises complex work involvinga significant need for interaction between team members, remotecollaborators that are not co-located with project management often havea difficult time establishing contextual knowledge relevant to theproject. For example, on a software development project, a developer inIndia may not fully appreciate the project requirements worked outthrough face-to-face meetings with the customer by U.S.-based projectmanagers. On the other hand, a project manager may not be able toquickly appreciate the subtleties of a technological issue encounteredby the development team without significantly interacting with thedevelopers. Such inefficiencies can be compounded by the fact thatdifferent team members may have different levels of experience andknowledge, thereby making it difficult to maintain quality.Additionally, differences in time zones between team members may createsubstantial lags in response time when critical issues arise, andprovide a limited amount of time in which multiple team members mayconference together. Further still, differences in culture or languagemay create difficulties when trying to understand implied instructionsfrom team management. A particular result of these collaborative hurdlesis, often, an inability of project management to quickly ascertain thestatus or progress of work being performed by remote team members.

Prior art solutions to such collaboration difficulties tend to be ad hocapproaches using existing, disparate content repositories andcommunication and tracking tools. For example, project team members mayattempt to use emails as the primary channel for communicating issues asthey arise or to use issue tracking software to maintain historicalcontext regarding how such issues were addressed. While such tools areindividually suited for the particular tasks for which they aredesigned, collectively, they typically are unable to provide thenecessary level of structure and support to maximize efficiency of thecollaboration team. Further, existing tools that may contain workflowfunctionality to formalize and structure standard types ofcommunication, e.g., issue tracking, risk management, documentversioning, do not account for informal communications that arenecessary to perform collaborative work. Stated another way, therecurrently are no systems or tools that provide coordinated operationbetween such separate collaboration tools. A consequence of thisshortcoming is a lack of context. As used herein ‘context’ comprises anyinformation that provides greater understanding of the subject matter ofa given communication or deliverable artifact, such as a document orportion of code, beyond the actual content of the item, e.g., historicalinformation concerning a specific issue, identification of specificparties having an interest in the specific subject matter,classification of the subject matter, etc. Such context incommunications between team members typically ensures more meaningfulcommunications, e.g., the difference between awareness of the content ofa communication and a true understanding of the implications of suchcontent. Therefore, a collaboration system or suite of tools thatovercome these problems would represent an advancement in the art.

SUMMARY OF THE INVENTION

The present invention overcomes the limitations of the prior artdescribed above through the use of an integrated collaboration system.The collaboration system in accordance with the present invention drawsupon three guiding principles in its structure and operation. First, itis necessary to organize communication channels between collaborationteam members. Second, it is necessary to build context aroundcommunications between team members. Third, wherever possible,relationships between collaborators should be enhanced. To this end, thecollaboration system of the present invention provides variouscomponents that allow currently-used communication channels, e.g.,electronic mail, instant messaging, etc., and content formats, e.g.,text, audio, images, video, etc., to be organized such that contextualinformation surrounding messages sent within the system is more readilycaptured and used to organize the messages.

Thus, in one aspect of the inventive collaboration system, a processingdevice (e.g., a user terminal) used to support communications betweenusers of the collaboration system is operative to capture (preferably,automatically) occurrence of at least one event—defined in accordancewith a project plan—caused by a user of the processing device. That is,the project plan, among other things, defines one or more events ofsignificance to the project being worked upon by a collaborative teamand that may be automatically captured. For example, in the context of asoftware development project, such events may include checking in/out agiven code module from a code library, or releasing a given set of codefor use in production.

Information regarding each such captured event is stored and an activityreport based at least in part upon the stored event information isprovided by the processing device (preferably via a controller) to atleast one other user of the collaboration system. The user may causereport annotations (which may comprise text, audio, images, video or anyother combination of human-perceivable information) to be associatedwith the activity report. A controller within the collaboration systemis employed to route the activity report (and any associatedannotations) to other users of the collaboration system. The recipientsof the activity report may submit their own annotations to thecontroller for association with the activity report. Furthermore, thecontroller may operate to aggregate the activity report with otheractivity reports of other users of the collaboration system, which otheractivity reports may likewise comprise associated annotations. Theresulting aggregated activity report may be provided to one or morecollaboration system users just like any other activity report. In oneembodiment of the present invention, the targeted recipient(s) of anactivity report (whether aggregated or otherwise) may be designated onan opt-in, subscription basis. Regardless, activity reportsautomatically generated in this manner may be used by collaboration teammembers to quickly ascertain the status and/or progress of work beingperformed by other team members despite great differences in locations,time zones, language, culture, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

The features of the present invention are set forth with particularityin the appended claims. The invention itself, together with furtherfeatures and attended advantages, will become apparent fromconsideration of the following detailed description, taken inconjunction with the accompanying drawings. One or more embodiments ofthe present invention are now described, by way of example only, withreference to the accompanied drawings wherein like reference numeralsrepresent like elements and in which:

FIG. 1 is a functional illustration of a collaboration system inaccordance with an embodiment of the present invention;

FIG. 2 is a schematic block diagram of a communication system inaccordance with an embodiment of the present invention;

FIG. 3 is a functional block diagram of a collaboration system inaccordance with an embodiment of the present invention;

FIG. 4 is a flow chart illustrating operation of a user terminal inaccordance with an embodiment of the present invention;

FIG. 5 is a flow chart illustrating operation of a controller inaccordance with an embodiment of the present invention;

FIG. 6 is a flow chart illustrating a distribution process in accordancewith an embodiment of the present invention;

FIGS. 7 and 8 illustrate various features of a user interface inaccordance with an embodiment of the present invention;

FIG. 9 is an illustration of an email interface in accordance with anembodiment of the present invention;

FIG. 10 is an illustration of an email input interface in accordancewith an embodiment of the present invention;

FIG. 11 is an illustration of a media capture input interface inaccordance with an embodiment of the present invention;

FIG. 12 is a flow chart illustrating operation of a user terminal inaccordance with another embodiment of the present invention; and

FIG. 13 is a flow chart illustrating operation of a controller inaccordance with another embodiment of the present invention.

DETAILED DESCRIPTION OF THE PRESENT EMBODIMENTS

Referring now to FIG. 1, a collaboration system 100 in accordance withthe present invention is functionally illustrated. The collaborationsystem 100 is essentially a communication system that is enhanced withfeatures that provide greater support to collaborative teams thancurrently available. In particular, the system 100 comprises one or moreuser interface components 102-110 and one or more back-end components120-126 communicating with each other via at least one communicationchannel 130. In a presently preferred embodiment, each of the interfacecomponents 102-110 and each of the back-end components 120-126 areimplemented using known software programming techniques. Using suchtechniques, suitable processing devices (such as desktop/laptop/handheldcomputers, mobile communication devices such as cellular phones,personal digital assistants, one or more server computers, etc.) mayoperate under the control of executable instructions to carry out thevarious functions described herein. However, those having skill in theart will appreciate that various other techniques may be equallyemployed, in whole or in part, to implement the operations of thepresent invention including, but not limited to, application specificintegrated circuits (ASICs), programmable logic arrays implementingstate machines, etc.

Generally, the interface components 102-110 serve as a mechanism for auser of the system 100 to generate communications or activity reportsfor distribution to other users of the system 100 while providinggreater ability to generate, preserve and use contextual informationthat fosters greater understanding among collaborators. For example, theinterface components may include a dashboard 102 that serves as acentral portal for accessing the various features of the collaborationsystem. In a presently preferred embodiment, the dashboard 102 isimplemented as a web-based, graphical interface, using techniques knownto those having skill in the art. Using the dashboard 102, a user of thesystem may access, create, and manage any communications that he/shegenerates or receives, control a profile of the user maintained by thesystem, access such profiles of other collaborators and access andmanage various content or media files generated/received by the user.

A communication template 104 serves as a standardized interface for thegeneration of one or more types of communications and correspondingmetadata. Preferably, the communication template 104 is based on one ormore existing, software-based communication applications, such asMicrosoft's “OUTLOOK” email application. As described in greater detailbelow, the metadata captured in this manner is preferably based on aplurality of standardized metadata attributes that are defined inaccordance with the particular needs of the collaborative project. Forexample, a software development team may have one set of metadataattributes that would be most useful, whereas an industrialmanufacturing team may have another set of metadata attributes thatwould be most useful. The one or more communication types supported bythe communication template 104 may be any commonly used types such asemail, instant messaging, short message service (SMS), etc. To supportsuch different services, the communication template 104 may comprisemultiple templates, one for each communication type, but each stillimplementing the standardized metadata attributes. Techniques forimplementing one or more templates of this type are well known to thosehaving ordinary skill in the art. Such multiple templates, if used,could be provided with a common user interface or maintained asseparately usable entities. Regardless, the standardized nature of thetemplates ensures that users are triggered to provide the most importantrelevant information for each type of communication.

Recognizing that the most convenient point for generating certaincommunications may be within particular tools used by the variouscollaborators, the present invention also provides for the integrationof communication interfaces into such tools. In the specific case ofsuch tools that are implemented as software programs, a plug-incomponent 106 may be provided. As known in the art, a so-called“plug-in” is a discrete software program implementing additionalfunctions that may be readily integrated into an existing softwareprogram using a standardized interface. In the context, for example, ofa software development project, such a plug-in implements an interfaceallowing a user to access and generate messages in a manner similar tothe communication template 104, but within an integrated developmentenvironment program in which developers are performing softwaredevelopment tasks. Those having skill in the art will appreciate thatimplementations other than plug-in programs may be equally employed forthis purpose.

The user interface components also comprise a multi-media capture agent108 used to generate content files by users of the collaboration system100. For example, the capture agent 108 may be implemented usingMicrosoft's “WINDOWS” Media Encoder application. As used herein, acontent file may comprise data or information represented in anyhuman-perceivable (preferably, digitally reproducible) form such astext, audio recordings, image recordings, video recordings orcombinations thereof represented in any of a number of well-knownformats. As such, multiple capture agents, such as those known to theskilled artisan, may be equally employed. As described in greater detailbelow, the content files generated by the capture agent 108, which ispreferably integrated with the dashboard 102 or that may operate as astand-alone component, may be associated with messages created withinthe system 100 either concurrently with or subsequent to generation ofsuch messages. Additionally, in one embodiment, an interface, such asthat illustrated in FIG. 11 and described in further detail below, maybe used to automate the creation of the standardized metadata for usewith content files created using the capture agent 108. Furthermore, thecontent files generated in this manner may also be used as annotationsto activity reports generated in accordance with the present invention.

Finally, a status tracker 110 is provided to generate activity reportson behalf of a user. Although illustrated as an “interface” component,the status tracker 110 is preferably implemented in such a manner as toallow automatic, autonomous or semi-autonomous operation. In general,the status tracker 110 is provided access to a project plan 112 (whichmay be implemented as a data structure stored in a suitableprocessor-readable medium). The project plan 112 (which may includedata/information concerning various milestones, performance goals,progress metrics, etc. that may be useful for project managementpurposes, as known in the art) preferably includes definitions of one ormore events having meaning within the context of a given collaborativeproject. Each event represents a significant occurrence that may beuseful in reporting work status and/or progress. For example, as notedabove, in a software development project, such events may concernspecific instances of using or handling software program modules, suchas checking in/out a program module from a module or code library. Moregenerally, such events may include more mundane occurrences such as (butby no means limited to) powering up/down of a user terminal, accesses toa given portion of a data storage network, instantiation of certainapplications, generation of communications to certain other users in thesystem, etc. Regardless of the exact definition of each pre-definedevent, it is preferred that each event be capable of capture (i.e.,recognition of its occurrence) in an automatic fashion. That is, it ispreferable if the status tracker 110 may capture such events withoutuser intervention (via the processing device in which the status tracker110 is implemented). For example, referring once again to softwaredevelopment examples referred to above, accesses to the module or codelibrary may be tracked in an automated fashion using known programmingtechniques. However, it is understood that user intervention in thecapture of certain events (e.g., notation of an in-person discussionbetween two or more collaborators) may be required in those instances inwhich such automation is not possible.

In a presently preferred embodiment, each time the status tracker 110captures occurrence of an event (either automatically or with userassistance), information regarding the event is stored. Thereafter, thestatus tracker 110 may generate one or more activity reports based onthe stored event information, which activity reports may be forwarded onto the back end components 120-126 for further handling. Techniques forgenerating such activity reports, which may simply be a compiledcategorized listing of an individual's activities, based on stored eventinformation are well known in the art. Although such activity reportsmay be generated at virtually any time or aperiodic interval, eitherautomatically or at the instigation of a user or other entity (such as anetwork administrator), it is presently preferred that they be generatedon a periodic basis or scheduled basis. For example, such reports may begenerated on a daily basis during normal work days during typicaloff-hours (e.g., between midnight and 6 AM local time relative to aspecific user terminal).

Generally, the back-end components 120-126 operate to managecommunications and content files generated by users of the collaborationsystem 100, including association of messages based on correspondingmetadata values, distribution of messages to various users (viacorresponding user terminals) of the system 100, as well as thedistribution of activity reports. To this end, a communicationconsolidation component 120 is provided to establish and maintain theassociations between the various communications (and, where necessary,content files). In the context of the present invention, an“association” between communications alludes to the circumstance inwhich messages concern related subject matter and may therefore beconnected in some manner to maintain context. In a presently preferredembodiment, such association is carried out through establishment of alogical link, such as a pointer, between stored messages. As describedbelow, the consolidation agent 120 ascertains when to establish suchassociations based on correspondence of metadata appended to themessages. Associations between messages are established in variousmanners known to those having ordinary skill in the art. For example, inone presently preferred implementation, messages sent within the systemare treated as records in a database. Links between such records areestablished using a technique known as polymorphic association. In thiscase, all records in the database are associated via foreign keys(pointers). More specifically, messages are sent to recipients (users,workgroups, focus areas) via a polymorphic relationship—thecommunication consolidation component 120 tracks the message primary key(an identification) as well as the primary key for the recipient(another identification) and the type of recipient. It then retrievesmessages sent to the current user as well as the workgroups/focus areasthat the user belongs to, by default. Similarly, responses to a messageare associated via foreign key relationships to other messages.Reference links are simply stored as text in the database record for themessage. Likewise, media or content files are related via many-to-manyrelationships between messages and media files.

In one embodiment, the communication distribution agent 122 operates toroute messages to users of the system 100 based on an interest in thesubject matter at hand and/or that are the direct, intended recipientsof each message. For example, in the context of a software developmentteam, a given manager may send messages concerning “bugs” that ariseduring development in the software to a group of recipients that have ininterest in the subject of “bugs” to the extent that they are impactedby, or may have an impact upon, the subject matter thereof.Additionally, or alternatively, the manager may wish to send themessages specifically to one or more selected recipients. To facilitatesuch groups (or work groups), individual users of the system may“subscribe” (or, alternatively, be “subscribed” by an initiator of amessage) to receive communications concerning certain subject matterintended for a recipient group as indicated by the metadata associatedwith each communication. In a more specific implementation, users mayinstead subscribe to specific discussions or topics. In this manner, thepresent invention provides the ability to automatically build greaterteam awareness with minimal additional burden on individual teammembers. Techniques for allowing users to subscribe to work groups, andfor managing such work groups, are well known in the art.

A handoff assistant 124 is provided as part of the back end todistribute the activity reports (as well as any associated annotations)received from various users, as well as store such activity reports asindividual records in a suitable storage mechanism. In a presentlypreferred embodiment, each activity report may be distributed to usersof the collaboration system (other than the contributing user, whomautomatically receives his/her own activity report) based on asubscription system. That is, each user may designate which activityreports he/she would like to be copied on (for example, throughconfiguration of user parameters that may be set via a suitable userinterface such as the dashboard 102). Presuming that a given subscriberis authorized to see the desired activity reports, the handoff assistant124 causes the selected activity reports to routed to the subscriberusing know communication techniques. Alternatively, the recipients ofactivity reports may be designated in a centralized manner, i.e.,through control of a network administrator or project coordinator, usingtechniques known in the art.

Further, the present invention allows recipients of activity reports tosubmit their own annotations for association with a given activityreport, which association is handled through the handoff assistant 124.For example, a first user may submit his/her activity report (viahis/her user terminal, either manually or automatically) for subsequentdistribution via the handoff assistant 124. Additionally, the first usermay also submit annotations prior to his activity report beingdistributed to other users (such as a next shift of workers, etc.).Alternatively, a second user, after having received the first user'sactivity report may decide to submit an annotation concerning the firstuser's activity report. Using the metadata-based techniques describedbelow, the second user's annotation may be associated with the firstuser's activity report, thereby allowing all subsequent recipients tobenefit from the additional context provided by the second user'sannotation.

A project status aggregator 126 operates to collect multiple activityreports received from various users of the system to provide aggregatedactivity reports. The aggregated activity reports may be distributed toone or more users of the system in the same manner as individualactivity reports described above, but with certain restrictions based onuser access levels. In alternate embodiments of the present invention,such aggregation may occur on demand or in synchrony (albeit, somewhatdelayed) with any periodic or scheduled generation of activity reportswithin the system. As an example of this latter embodiment, in the caseof a collaboration team having separate groups in the United States,France and Japan, individual activity reports may be scheduled forgeneration at the end of the working day in each country on a dailybasis. Shortly after 5 PM (or appropriately designated end of day time)in each country, the project status aggregator 126 may generateaggregated activity reports for the groups of team members in thatcountry and distributed to designated team members in each of the othertwo countries. In this manner, activity reports for entire groups orsubgroups of collaborators may be consolidated into a single report formore efficient review by targeted recipients. Additionally, the dataaggregated as a result of these reports can be used to automaticallyupdate project plans to help track and manage overall status. Varioustechniques for automatically updating project plans based on(aggregated) activity reports are known to those having ordinary skillin the art.

FIG. 2 illustrates a schematic block diagram of a communication system200 that may be used to implement the collaboration system 100 inaccordance with one embodiment of the present invention. Generally, thesystem 200 comprises a plurality of user terminals 202 in communicationwith each other and a controller 204 via one or more communicationchannels 206. In a presently preferred embodiment, each of the userterminals 202 comprises a processor-based device such as a computer (orother device) comprising one or more processors 209 in communicationwith at least one storage component 210. The processor(s) 209 maycomprise microprocessors, microcontrollers, digital signal processors,etc. or combinations thereof operating under the control of executableinstructions stored in the storage component(s) 210. The storagecomponent(s) 210 may comprise any combination of volatile/non-volatilememory components such as read-only memory (ROM), random access memory(RAM), electrically erasable programmable read-only memory (EEPROM),etc. The executable instructions stored in the storage component(s) 210may be particularly used to implement processing as described in greaterdetail below. However, as known in the art, the user terminals 202 maybe implemented, in whole or in part, using other components such asASICs, programmable logic arrays, etc. that may operate under softwareor hardware control.

As further illustrated, each user terminal 202 preferably comprises adisplay 211 in communication with the processor(s) 209. As known in theart, the display 211 may comprise an integral or external display suchas a cathode-ray tube (CRT), liquid crystal display (LCD), lightemitting diode (LED) display, etc. Techniques for providing display datato a display are well known in the art. In a similar vein, the userterminals 202 preferably include user input/output components 212 aswell as one or more communication interfaces 213. The I/O components 212may comprise any mechanism that allows a user of the user terminal 202to interact therewith, e.g., a mouse, keyboard, microphone, video and/orstill image camera, speaker, etc. The communication interface(s) 213support the use of the one or more communication channels 206 andtypically comprise any combination of hardware and/or software elementsnecessary to terminate physical links (e.g., Ethernet, wireless, etc.)or communication protocols (e.g., HTTP, SOAP, SSL, TCP/IP, etc.).Techniques for implementing the interface(s) 213 are well known to thosehaving skill in the art.

As noted above, the communication channels 206 may comprise any one orcombination of wired or wireless communication channels, depending onthe capabilities of the terminals 202 and/or controller 204.Additionally, the communication channels 206 are further defined by thetype of communications supported thereby. For example, emailcommunications, voice communications, instant messaging (IM)communications, SMS communications, multimedia messaging service (MMS)communications, etc. may all be supported by different types ofcommunication channels, as known to those of skill in the art. A benefitof the present invention is that the metadata provided in accordanceherein allows the collaboration system to organize communicationsregardless of the underlying type of communication channels employed.

As shown, the controller 204 preferably comprises a processor-baseddevice comprising at least one processor 214 and at least one storagecomponent 216 as described above with regard to the user terminals 202.In a presently preferred embodiment, the controller 204 is implementedusing one or more server computers as known in the art. Additionally,the controller 204 is preferably in communication with a database 208that, as known in the art, can also be implanted using one or moreserver computers. Generally, the controller 204 implements thefunctionality described above relative to the back-end components120-126 whereas the database 208 stores the data (i.e., messages,content files, links therebetween, activity reports, aggregated activityreports, etc.) sent between user of the system 200.

An implementation of a collaboration system 300 showing additionaldetail regarding implementation of the back-end is further illustratedwith regard to FIG. 3. In particular, the collaboration system 300 asshown includes a plurality of user interfaces 301 (only one shown) incommunication with the back-end 303. Preferably, the user interface 301is implemented via the user terminals 202 and carrying out the functionof the interface components 102-110 described above. The system 300illustrated in FIG. 3 is particularly adapted for use in conjunctionwith software development, although the present invention is not limitedto this particular application. Regardless, as illustrated, the userinterface 301 includes a development environment plug-in 302, a webinterface 304, an email toolbar and interface 306, an instant messaging(IM) or chat interface 307 and a stand-alone media capture interface 308each operating in conjunction with a metadata generator 309. As known inthe art, the development environment plug-in 302 may comprise a plug-insuitable for communicating and operating with a suitable softwaredevelopment program, such as the “ECLIPSE” integrated developmentenvironment software program. In general, the plug-in 302 implementssubstantially similar functionality as the web interface 304, emailtoolbar interface 306, IM interface 307 or any other interface thatprovides the ability to generate messages, as described below. The webinterface 304 preferably implements the functions of the dashboard 102,described in greater detail below. Similarly, the email interface 306and/or IM/chat interface 307 preferably implement(s) the functions ofthe communication template 104, also described in greater detail below.The stand-alone media capture interface preferably implements thefunctions of the multi-media capture agent 108, described in greaterdetail below.

The metadata generator 309 operates in conjunction with the various userinterface components 302-308 to generate metadata values in accordancewith standardized metadata attributes. For example, the metadatagenerator 309 may receive user selections corresponding to predefinedmetadata input values, or may comprise received data entered via auser-definable metadata value input field, as described below withfurther reference to FIGS. 8 and 9. Additionally the metadata generator309, using known techniques, may populate predefined metadata inputfields based on variables known to the system such as date, time, useridentification, communication type, etc. Alternatively, moresophisticated techniques can be used to implement the metadata generator309, particularly techniques that allow metadata to be automaticallygenerated based on analysis of the messages created via the variousinterfaces 302-308. For example, in the case of communications employinga text format, individual communications can be scanned by the metadatagenerator 309, using known text parsing techniques, to identify keywords that may be used as the metadata. Further still, although themetadata generator 309 is illustrated as a single element in FIG. 3(reflective of the standardized nature of the metadata generatedthereby), in implementation, using techniques known to those of skill inthe art, it may be preferable to provide separate components for each ofthe various user interface components 302-308. Regardless of itsimplementation, the metadata generator 309 provides metadata values foreach communication (message) provided to the back end 303. Through theuse of such standardized metadata attributes and values, the presentinvention is able to create associations between disparate communicationchannels, thereby creating valuable context to such communications.

As shown, the back end 303 preferably comprises a plurality of servercomputers 310-320 arranged in a suitable network configuration, a fairlytypical example of which is illustrated in FIG. 3. Suitable servercomputers for implementing the functions of each of the servers 310-320described below, as well as modifications to the network configuration,are well known in the art of database-backed dynamic web applications.In a presently preferred embodiment, additional implementationtechniques are employed, such as using a cluster of virtual servers toimplement the application web server 312, or the use of multipleclusters of servers per project collaboration team. Other refinementsmay be apparent to those having ordinary skill in the art. Typically,each of the servers 310-320 communicates with each other and/or withuser terminals via a suitable communication protocol, such as TCP/IP. Inthe embodiment shown, a proxy server 310 is provided as the interface tothe back end 303. In accordance with known techniques, the proxy server310 provides users of the system 300 indirect access to the services andresources made available by the other back end servers. In theillustrated configuration, the proxy server 310 is in communication withan application web server 312. In a presently preferred embodiment, thecombination of the proxy server 310 and the application web server 312implements the functions of the controller 204 (i.e., the back-endcomponents 120, 122 described above and in further detail below). Theapplication web server 312 is in communication with a database server314 that stores one or more project profiles, user profiles andcommunication preferences, identifications o work groups andrelated/subscribed users, message content, metadata for messages andcontent files, pointers to content files and the linking informationbetween messages. As known in the art, the email server 316 supportscommunications between user terminals using an email communicationprogram. More particularly, email communications originating from agiven user's terminal (and corresponding interface 301) are firstprocessed by the proxy and web application servers 310, 312 (asdescribed below). Thereafter, such communications can be sent to theintended recipients (e.g., workgroups and/or specific users) via theemail server 316 using well known techniques.

The additional servers illustrated comprise an active directory server318 in communication with the application web server 312. As known inthe art, the active directory server 318 allows one or more systemadministrators to control configuration/operation of the variouscomponents within the system 300, including the user terminals. Asoftware development server 320 is also shown in communication with theapplication web server 312. In the context of software developmentprojects, the software development server 320 may implement a suitableworkflow automation tool such as IBM's “RATIONAL” “CLEARQUEST” program.Of course, other servers running applications appropriate for use ondifferent types of collaborative projects may be equally incorporated,using known techniques, as dictated by the particular needs of suchprojects.

Referring now to FIG. 4, a flowchart illustrating operation of a userterminal in accordance with the present invention is shown. As notedpreviously, the operations illustrated in FIG. 4 are preferablyimplemented using stored, executable instructions that control operationof one or more suitable processors. As shown, the processing of FIG. 4is divided into two separate, parallel paths that may be carried outsubstantially simultaneously or at different times. Thus, along a firstpath, processing begins at block 402 where a first message is created bya user of the terminal using a message creation component. As known inthe art, a message can be created in any of number of ways depending onthe format of the message to be created. For example, an email messagecan be created through the use of a suitable email program, such asMicrosoft's “OUTLOOK” email program, by typing the message using akeyboard. Similarly, an instant messaging program may be used to createan instant message or the dashboard 102/web interface 304 may be used tocreate a new message, as described below. Regardless of the manner inwhich the first message is created, processing continues at block 404where a first plurality of metadata values are appended to the firstmessage. As used herein, appending metadata to a message encompassesinclusion of the metadata in the message itself. For example, themetadata may be transmitted within the same electronic message“envelope” as the message content itself, or may be directly embedded inthe message content. Alternatively, the metadata may be storedseparately from the message content and “appended” by virtue of alogical link (e.g., pointer values to physical storage locations)between the two. As noted previously, the metadata values correspond toat least some of a plurality of metadata attributes that have beenstandardized in accordance with the needs of the users of the system.For example, in a software development environment, such standardizedmetadata attributes may be categorized by type of communication beingsubmitted (e.g., regarding a problem found, asking a question concerningrequirements, making an announcement, etc.); by the groups potentiallyimpacted by the communication (e.g., the development group, management,the testing group, etc.); by relevant references (e.g., links to othersystems or other users within the system); and/or by status (e.g.,priority, urgency, state of completion, etc.) Additional systemgenerated metadata may include the date and timestamp of messagecreation or modification, the user creating or modifying the message.Once again, the particular standardized metadata attributes are notnecessarily limited to those described herein, and may be particularlyselected according to the needs of a particular project.

Thereafter, at blocks 406 and 408, the processing described aboverelative to blocks 402 and 404 may be respectively repeated for thecreation of a second message and appending of a second plurality ofmetadata values. Note that the first and second messages do not have tobe created by the same message creation component nor do they have to becommunicated by the same communication channel. So long as they bothhave their standardized metadata values appended thereto, the fact thatthey have been created using different message types (e.g., email,instant messaging, web interface, plug-in interface, etc.) will notaffect the ability of the instant collaboration system to establishcontext between the two messages. That is, assuming the first and secondmessage are related in some fashion, the first and second pluralities ofmetadata values should compare favorably such that the first and secondmessage may be subsequently associated together.

In parallel with the first path described above, the second pathillustrated in FIG. 4 begins at block 410 where a user creates a contentfile. As noted above, various tools may be employed to create a contentfile depending on the format of the content file to be created, i.e.,text, audio, images, video, combinations thereof, etc. Additionally, thecontent file may be created well before or after or substantially at thesame time as a message with which it is subsequently associated. Asnoted previously, corresponding standardized metadata values arepreferably appended to content files when such content files are addedto the collaboration system, i.e., when the content files are created oruploaded. To this end, a suitable interface may be provided to ensureuniform capture of the standardized metadata, an example of which isfurther illustrated in FIG. 11.

As shown in FIG. 11, the interface 1100 comprises a number of user inputmechanisms (e.g., text boxes, drop down menus, etc.) that allow a userto enter metadata input values. Note that the examples illustrated inFIG. 11 are not intended to be exhaustive of such input mechanisms orthe types of metadata that may be captured. In the illustrated example,a text box 1102 is provided for capturing a subject indicator, e.g., thesubject matter to which the content file relates. In a similar vein, adetails text box 1104 is provided to capture additional informationconcerning the content file. That is, the details text box 1104 isintended to be freeform, allowing users to provide information/metadatathat would be useful to viewers. For example, in a software developmentproject, a user may use this functionality to walk the viewer through afunctional problem via a screencast (i.e., a digital recording ofcomputer screen output, often containing audio narration), where thetext box 1104 might be utilized to provide prerequisite steps. A dropdown menu 1106 is provided as a means for selecting a work group. Inthis implementation, the drop down menu 1106 provides a predefined listof available work groups (e.g., in the context of a software developmentproject, a Project Management group, Technical Architecture group,Requirements group, Application Design group, Development group, Testinggroup, Communications group, Deployment group, etc.). A reference linktext box 1108 allows a user to enter, in this example, a website addressof a website that includes additional relevant information. Of course,other types of addresses (e.g., internal network addresses, etc.) couldbe equally employed. Further still, a discussion pull down menu 1110 isprovided that allows a user to select a particular discussion (asdescribed below) to associate the content file with. In this instance, alist of discussions are maintained (for example, by the controller 204),which list is used to populate the populate the various pull down menuselections. Finally, suitable buttons are provided that allow a user toaccept his/her selections 1112 or discard (cancel) 1114 them inaccordance with well known user interface paradigms.

The content file created at block 410 is preferably stored at acentralized location, e.g., at the web application server 312, althoughit is understood that any suitable storage means in virtually anylocation may be used for this purpose. When being stored, the contentfiles may be uploaded automatically (after being created locally at auser terminal) when the file is created through the system applications,e.g., the media capture agent 308, or created locally by the user in anapplication external to the system and uploaded, e.g., to the web server312, at a later time through the dashboard 102. Regardless, at block412, the content file thus created and stored may be associated with amessage, such as a message created in accordance with blocks 402-408 asdescribed previously. Once again, the association of the content filemay be carried out through actual co-storage of the message and thecontent file, or, in a presently preferred embodiment, via logical linksbetween the two (which links are preferably stored, along with themetadata in the database 314). Also, the step of associating the contentfile with the message may occur substantially simultaneously with or atanytime after creation of the message. For example, as described belowrelative to FIGS. 8 and 10, either the dashboard 102 or communicationtemplate 104 may be used to associate the content file with the message.

Referring now to FIG. 5, a flowchart illustrating operation of acontroller in accordance with the present invention is shown. As notedabove, the operations illustrated in FIG. 5 may be implemented usingstored, executable instructions that control operation of one or moresuitable processors. Beginning at block 502, the controller receivesfirst and second messages from user terminals. Both the first and secondmessages have metadata appended thereto as described above. Note thatthe first and second messages may be received at the controller within arelatively short period of time or at substantially different times,e.g., weeks or even months apart. In order to determine whether thefirst and second messages should be associated with one another, acomparison of their respective metadata values is undertaken at block504. As known to those having skill in the art, a variety of techniquesfor comparing metadata values with each other are available and furtherdescription here is not necessary. More importantly, whether the twomessages should be associated with each other depends on the relativefavorability of the comparison performed at block 504. The standard forassessing such favorability is a matter of design choice. For example,in a presently preferred embodiment, substantially identical metadatavalues (of at least a subset of the possible standardized metadataattributes) are required. More specifically, it is currently preferredto find a favorable comparison when a given message is a reply to aprevious message, hence resulting in virtually identical metadatavalues, or when the metadata values corresponding to work groups areidentical. In this latter vein, association may be proper where arelatively small number of high priority metadata values substantiallymatch. For example, two emails having different creation times andshowing different “subject” lines may nevertheless be properlyassociated together if they have the same author and recipients andcontain one or more identical keywords. The present invention is notnecessarily limited by the nature of the test used to determine theexistence of a favorable comparison.

If the comparison of block 504 is favorable, the first and secondmessages are associated with each other at block 506. As noted above,this is may be accomplished by establishing one or more logical links orpointers (e.g., through the use of foreign keys) between the messages.For example, each message could include a pointer to the physicallocation in storage of the other message. References to otherdiscussions (i.e., threads of messages) may likewise be associated viaappropriate pointers. In the above-mentioned case of reply messages,such pointers are not necessary as known to those of skill in the art.After establishment of the association at block 506 (regardless of howits implemented), or if the comparison at block 504 was unfavorable,processing may continue at block 508 where it is determined whether acontent file has been received by the controller. The manner in whichthe content file is received may vary, including directly receiving thecontent file as in the case of an included email attachment, orindirectly as in the case of receiving a reference (e.g., a pointer) tothe content file within the centralized, back end storage (e.g., the webapplication server 312) or in a local user terminal. In a presentlypreferred embodiment, the dashboard 102 may be used at a user terminalto manipulate graphical representations of content files and therebyassociate them with specific messages. Regardless of the manner in whichthe controller receives the content files, processing thereaftercontinues at block 510 where the content file is associated with amessage. Those of skill in the art will recognize that individualcontent files could be associated with more than one message. Onceagain, such one-to-one or one-to-many association may be accomplishedthrough the use of pointers to storage locations. Other techniques maybe used as a matter of design choice.

In another aspect of the present invention, the distribution of messagesis controlled, at least in part, by the particular members of a groupdesignated to receive the messages, the preferred communication channelsof such members and the workload of each recipient. An example of such aprocess in accordance with a presently preferred embodiment isillustrated in FIG. 6. Once again, the processing illustrated in FIG. 6is preferably implemented using appropriately programmed processors ofthe types described above, both within the user interface 301 and backend 303. As illustrated, the various processing blocks 602-634 may begenerally grouped into three distinct groups. In a first group,comprising blocks 602-606, information concerning availability andpreferred communication channels of a user is managed. In a secondgroup, comprising blocks 608-610, initiation of discussions, asdescribed below, is provided. Finally, in the third group comprisingblocks 612-634, distribution of specific messages, including delivery tospecifically designated recipients is further illustrated.

Beginning at block 602, a user of the system may provide any necessaryinformation to configure a particular contact type, i.e., communicationchannel. That is, in a presently preferred embodiment, a user candesignate specific communication channels to be used to contact thatuser in accordance with rules or preferences of the user's own design.In a preferred embodiment, the dashboard 102/web interface 304 is usedfor this purpose, as described below. Thus, for example, during normalbusiness hours in which the user does not have previously scheduledappointments, the user may designate that his/her office email accountshould be used to receive incoming messages without any further attemptsto alert the user. Conversely, after normal business hours or duringperiods of time during which the user has previously scheduledappointments, the user may designate that, in addition to routing allincoming messages to his/her email account, a message should also besent to the user's mobile phone via, for example, SMS. Those havingordinary skill in the art will appreciate that known techniques may beused when establishing such rules. Generally, the configurationinformation provided by the user at block 602 may be stored in anysuitable storage device although, in a presently preferred embodiment,it is stored by the database 208.

In parallel, at block 604, scheduling information for the user may beimported into the system, i.e., via the web server 312. In a presentlypreferred embodiment, the scheduling information may compriseinformation taken from an electronic calendar or similar mechanism. Asknown in the art, such scheduling information is indicative of the time,places, etc. of appointments for a given user and may be encoded in aconventional manner. Regardless, at block 606, contact availability forthe user is established based on the imported scheduling informationfrom block 604 when overlaid with the contact rule types established atblock 602. In this manner, the present invention allows users to veryspecifically tailor the communication channels at their disposal totheir personal needs and schedules.

Within the second group of blocks described above, i.e., concerning theinitiation of discussions, processing begins at block 608, where a usermay initiate or respond to a discussion using any of the above describeduser interfaces, e.g., the dashboard 102, communication template 104 orplug-in interface 106. Using known techniques (such as predeterminedpull-down menu entries or the like in a graphical user interface), theuser can elect to create a new discussion or reply to an existingdiscussion. As used herein, a discussion is a thread of associatedmessages (and, possibly, content files, as described above) concerning aparticular topic or subject. The “breadth” of such discussions, i.e.,the size of the group of desired recipients, may be controlled in partthrough the manner in which the discussions are initiated. For example,by initiating a discussion to a specific workgroup, as illustrated atblock 610, a relatively broad audience may be established initially.Alternatively, or in addition, selection of specific, individualrecipients of a discussion allows the creator of a discussion to moreclosely manage its intended audience. Regardless, as described below,the controller 204, when it receives a message to be distributed todesignated recipients and workgroup members, undertakes a two-prongeddelivery process in which it evaluates each recipient's availability forindividual delivery of the message, as well as a general “posting” ofthe message to a discussion thread that is always available via thedashboard 102, as described below.

Within the third group of blocks, i.e., concerning the distribution ofmessages to their designated recipients, processing is once again splitalong two parallel paths. Along the first path, embodied by block 612,all messages (whether the beginning of a discussion or in response to anexisting discussion), are posted to the discussions to which theypertain. In a presently preferred embodiment, this includes publishingthe message as part of a discussion to be displayed on the dashboard102. That is, using the association process described above, the messageis posted as part of a discussion thread based on its association withone or more messages in that thread.

In parallel, and assuming individual recipients of a message weredesignated at block 610, processing proceeds in parallel at block 614where the controller 204 determines availability of recipients of themessage, including individual members of any designated work group, byreference to such recipients' respective scheduling information. If, atblock 616, it is determined that individual recipients are notavailable, processing continues at block 626 where the message is sentvia a default communication channel to such recipients. Such defaultcommunication channel is preferably a relatively ubiquitous,non-intrusive channel type, such as email, although other channels maybe used for this purpose as a matter of design choice.

In one aspect of the present invention, the distribution of messages todesignated recipients may be based, at least in part, upon the workloadsof each designated recipient. This is illustrated at block 618 where theindividual workloads of each selected recipient is determined. In apresently preferred embodiment, individual workloads are assessedthrough reference status tracking data 620. Status tracking informationrefers to status reports of individual users concerning their dailyactivities including, but not limited to, goals achieved, activitiesengaged in, etc. as provided by individual users of the system.Virtually any method (although preferably automated) for gathering suchinformation may be employed by the present invention. For example, apresently preferred technique for generating such status trackinginformation is disclosed in co-pending U.S. patent application havingattorney docket number 33836.00.0140, filed on even date herewith andincorporated herein in its entirety. Those having ordinary skill in theart will appreciate that various other techniques for determining theworkload of individual recipients may also be used with the presentinvention. In accordance with this embodiment, those recipients having afavorable workload are selected to receive the message. For example, adesignated recipient having a currently excessive workload may beexcluded from receiving the message so as to minimize the burden placedon that particular user. Conversely, the user, having a currently lightworkload may be selected as a recipient as it is presumed that the userwill have the necessary time to consider the message. Those having skillin the art will appreciate that various techniques may be employed todetermine the favorability of an individual's workload. For example, inone embodiment, at least three factors are combined to assign eachrecipient an individual score, including the recipient's activity asindicated by the specific tasks assigned to the recipient per a projectplan as well as previous messages sent to the recipient. Additionally,task alignment between the subject matter of the message and thedesignated recipient's assigned task may also be assessed for thispurpose. By combining metrics representative of these three factorsusing known techniques (e.g., total score, average, weighted average,etc.) the individual scores may be assigned and compared to a suitablethreshold selected as a matter of design choice. Regardless of themanner in which workload is determined and assessed, processingcontinues at block 622, it is determined whether each individualrecipient is available based on his/her workload per block 618.

Thereafter, processing continues at block 624 where it is determined,for each remaining recipient, if the recipient has a communicationpreference for receiving such messages. If not, processing continues atblock 626 where the message is sent via the default communicationchannel as described above. If, however, the recipient has designated apreferred communication channel, processing continues at block 628 wherethe message is sent to each such recipient via his/her preferredchannel.

Regardless whether a given message has been only generally posted as perblock 612, sent via a default channel to as per block 626 or viapreferred channel as per block 628, processing thereafter continues atblock 630. At block 630, it is determined whether a response has beenreceived (by the controller) to the message posted at block 612 or sentat block 626, 628. In one embodiment of the present invention, it may bedesirable to escalate the importance of the message in the event aresponse has not been received to that message, as illustrated at block632. In this context, such escalation may include sending the message toother recipients as indicated by a project plan. For example, theproject plan may include listings of each user's supervisor and thesupervisor's contact information. In one embodiment of the presentinvention, the threshold for determining whether to escalate a givenmessage is based, at least in part, upon designations assigned by themessage initiator. For example, a specific period of time for responsemay be assigned, such as “within the next two hours”, etc.Alternatively, specific priorities may be assigned with theunderstanding that higher priority messages are escalated more quicklythan lower priority messages (in accordance, for example, with a definedescalation scheme defined by a project plan). Further still, projectstructure according to the project plan may be employed for targetingspecific, additional recipients. Thus, if escalation is required, themessage could be sent to the supervisors of one or more of theoriginally intended recipients. In the process of selecting suchadditional recipients according to the escalation need, the previouslydescribed process of assessing a recipients availability (i.e.,immediate availability per his/her calendar, work load availability perthe multifactor assessment) may employed. If, on the other hand, aresponse is received at block 630, processing continues at block 634where the status of the discussion to which the message pertained isupdated. For example, such update of status may include closing out thediscussion, raising priority of the discussion, or any other appropriatestatus update.

Referring now to FIGS. 7 and 8, an exemplary web application-based userinterface 700 in accordance with the present invention is furtherillustrated. Techniques for implementing such graphical user interfacesare well known to those having ordinary skill in the art. In accordancewith the present invention, the interface 700 is an implementation ofthe dashboard 102 described above, although it is understood that otherimplementations of the dashboard 102 may be equally employed. To thisend, and as shown, the interface 700 comprises a title bar 702 and adisplay window 704 in a manner similar to the desktop interface paradigmused by many computer operating systems. The title bar 702 may include asearch box 706 implemented and operated in a conventional manner, aswell as an account selection and logout mechanisms 708, 710 implementedin this example as textual hyperlinks.

Within the display window 704, a plurality of user selection mechanisms712-722 are illustrated as selectable buttons. In particular, a Recordbutton 712 is provided that may be selected to instantiate one or moremedia capture agents as described above. For example, assuming that theRecord button 712 has been selected, a record window 734 is illustratedhaving displayed therein a further plurality of selectable buttons,including a video recording selector 736 that may be used to instantiatea video recording program, a screen capture selector 738 that may beused to capture an image of a screen on a computer, a screen capture andaudio recording selector 740 that may be used to capture one or morescreen shots while simultaneously recording audio, and an audio selector742 that may be used to initiate audio recording only. Other recordingtypes or combinations of types may be equally employed as a matter ofdesign choice. Start and stop buttons 744, 746 are provided to initiateand terminate recordings after the desired recording mode is selected.

A Discussion button 714 is provided to instantiate a discussion window724 that may be used to view user-selectable discussions (i.e., one ormore associated messages and, possibly, content files) relevant to auser (or a group of which the user is a member). By selection of anindividual discussion item, a window setting forth the relevant messages(and associated content files) may be displayed. In a presentlypreferred embodiment, each item may include a variety of informationincluding a discussion identifier 725 and a discussion type 726. Theidentifier 725, preferably automatically provided by the controllermanaging the discussions, may comprise any indicia that allow adiscussion to be uniquely identified (in the illustrated example, aunique numerical identifier), and the discussion type 726, preferablyuser-configurable, sets forth some attribute value of the discussionuseful for categorizing separate discussions. In the example shown, eachof the discussions is of the “Bug” type, meaning that the discussionconcerns a problem identified in the software being developed by thecollaborative team. Of course, other types may be defined as a matter ofdesign choice. Note that the example in FIGS. 7 and 8 illustrate onlythree discussions; in practice, many more discussions (or fewer) may bedisplayed using, for example, a scrolling window. A subject indicator728 allows for a simple, short description of the subject matter of thediscussion. The submitter and date indicators 730, 732 respectivelyindicate the identity of the person that initiated the discussion andthe date on which the discussion was initiated. Finally, priorityindicators 733, which may be associated with corresponding ones of thediscussions, may be provided as a visual indicator of the relativelyimportance or urgency of each discussion. As described below, thepriority of a discussion may be set by the user initiating thediscussion or modified by the initiating user (or, alternatively, otherusers) at a subsequent time using, for example, the correspondingpriority indicator 733 presuming that the indicator 733 is madeuser-selectable and modifiable using known techniques. In a presentlypreferred embodiment, the attributes 725-733 of each discussion may beused to sort and/or filter the displayed discussions in accordance withknown sorting and filtering techniques.

With further reference to FIG. 8, the My Media button 716 is used toinstantiate a media window 802 that allows a user to view informationconcerning one or more media (content) files created or received by thatuser. For example, as shown in FIG. 8, the listing for each media filemay include a media file identification 803 that comprises any indiciathat may be used to uniquely identify the corresponding media file. Amedia type indicator 804 is also provided to help identify the type ofmedia used to record the content file, e.g., audio, video, screen image,etc. A subject indicator 806 provides a brief textual description ofeach content file. As before, the submitter and date indicators 808, 810indicate who created the file and when the file was created.

One feature of the present invention is the ability to associate themedia or content files with particular messages or discussions via theweb application interface 700. In particular, so-called “drag-and-drop”functionality may be employed to allow a user to drag a file icon 812using an input selector 811 to a targeted discussion 814 and, by thisaction, cause the media file underlying the file icon 812 to beassociated with the targeted discussion 814. Using known communicationtechniques, this action may cause a message to be sent to the controller204 indicating that the media file is to be associated with thediscussion or message. In this manner, significant context may beestablished for each given discussion, thereby allowing team members todevelop better understanding of the communications being exchanged.

In addition to the buttons 712-716 described above, a People button 718may be provided thereby allowing a user to view or search a listing ofother collaborators using the collaboration system. Using this mechanismto identify specific collaborators, profiles of each selectedcollaborator may be viewed to view current profile information. Forexample, such profiles may include a picture of the collaborator,contact information (including preferred contact modalities), titles,work locations, group memberships, time zone information and presenceinformation (e.g., currently logged in, busy, etc.) of eachcollaborator. In this manner, individual collaborators may quickly learnabout each other. A Search button 720 provides an alternate method toaccess search functionality and the My Profile button 722 allows eachuser to update his/her own personal profile information, which mayinclude designations of what types of profile information may be viewedby different entities, e.g., certain key personnel may be allowed toview a manager's home contact information whereas other personnel may berestricted from viewing such information. In accordance with blocks 602and 604 described above relative to FIG. 6, the My Profile button 722may be used to invoke the necessary user interface(s) (as known in theart) to manage/edit communication channel preferences and rulesregarding same, as well as the user's scheduling information.

Referring now to FIG. 9, an implementation of a communication toolbar isillustrated in the form of an exemplary email interface 902. Inparticular, the email interface 902 is based on the familiar Microsoft“OUTLOOK” email program interface and includes a title bar 904, a menubar 906 comprising the typical email menu items and one or more toolbars908, 910, and a display window 912 (in this case, displaying a user's“Inbox”) as known in the art. Additionally, a user input mechanism 914is provided (in this case, in the form of a pull down menu) that allowsa user to select one of a plurality of selectable predefined metadatainput values 916. As known to those having skill in the art,user-selectable input mechanism 914, rather than providing a predefinedlist of potential metadata values 916, may instead comprise auser-definable metadata value input mechanism such as a blank text box.Additionally, although a single input mechanism 914 is illustrated inFIG. 9, it may be desirable to include a plurality of such mechanisms(either identical or different in operation) to accommodate thepossibility of entering multiple metadata values. This is furtherillustrated with respect to FIG. 10.

FIG. 10 illustrates a message window 1002 that may be instantiated inresponse to selection of the “ask a question” metadata value 916illustrated in FIG. 9. As shown, the message window 1002 includes thefamiliar menu bar 1004 and message editing window 1024 employed by manyemail programs. A control bar 1006 is provided that sets forth varioususer-selectable control buttons including a send button 1008 and fileattachment button 1010, which may be used to append content or mediafiles to the message, as known in the art. In furtherance of thecreation of metadata, a workgroup button 1012 and a focus area button1014 are also preferably provided. The workgroup button 1012 allows auser to select from a list of predefined workgroups, e.g, ProjectManagement, Technical Architecture, Requirements, Application Design,Development, Testing, Communications, Deployment, etc. that reflect theparticular organization of the collaborative team, with each possibleselection comprising a potential metadata value. In a similar vein, thefocus areas button 1014 may allow further definition of relevantentities within each workgroup as designated by particular functionswithin each workgroup, or particular issues that are typicallyassociated with a given workgroup. In a presently preferred embodiment,both the workgroup and focus area entries may be defined as a set ofcustomized values. In this manner, useful, context-building metadataconcerning the message may be captured and stored for use as describedabove.

Further metadata input mechanisms are illustrated in the form ofaddressing inputs 1016 comprising the familiar data entry fields forrecipients of the message (the “To” and “Cc” fields), the subject of themessage (in this instance, automatically prefilled by a “Question”indicator as dictated by the original selection of the “ask a question”metadata value) as well as an attachment input field. An urgency inputselector 1018 is provided to allow a message creator to set an urgencyor priority level for the message using, in this instance, a drop downmenu. Further still, the combination of a references field 1020 andcorresponding add button 1022 allows a user to selectively addadditional information to the message, such as information concerningrelevant website addresses, contact people or content files. Each ofthese input mechanisms constitutes an additional source of metadatavalues that may be appended to the resulting message.

As noted previously, while the example of FIGS. 9 and 10 concerns anemail interface, similarly functioning interfaces may also be used todevelop templates for other communication modalities, such as theabove-mentioned IM, SMS or MMS channels using techniques known to thoseof skill in the art. Additionally, any combination of the input anddisplay mechanisms described above with regard to FIGS. 7-10 may beincorporated into a suitable plug-in component 106 that generates anappropriate interface within the corresponding main program for which itis designed, again using known implementation techniques. For example,in the context of a software development tool, an interface may beprovided that lists the same information shown in the discussion window724 described above. In this manner, a more effective presentation ofdevelopment-related communications may be provided.

Referring now to FIG. 12, further processing concerning generation ofactivity reports by user terminals is described. As noted above, theoperations illustrated in FIG. 12 may be implemented using stored,executable instructions that control operation of one or more suitableprocessors. As shown, the processing of FIG. 12 is divided into twoseparate, parallel paths that may be carried out substantiallysimultaneously or at different times. Thus, along a first path,processing begins at block 1202 where occurrences of one or more events,defined in accordance with a project plan, are captured by the userterminal. As noted above, the occurrence of such events is preferablydetectable in an automatic fashion, thereby relieving a user from havingto manually enter activity data. In accordance with presently preferredembodiments of the present invention, such events may include completionof a designated task and/or usage of an element within the collaborationnetwork. As used herein, an element may comprise any unit or collectionof units of data stored within a network, such as a content file, asoftware module, etc. and usage thereof may constitute any of a numberof well known operations, including but not limited to accessing,reserving, modifying, copying, etc. such elements. Although it ispreferred that event capture occur in a substantially automatic fashion,this does not preclude the possibility of “manual” event capture. Inthis instance, the processing at block 1202 may comprise receiving inputfrom a user of the terminal concerning the event. This may occur in thecase of an activity or task that is not performed with the use of theuser terminal, or that is not otherwise manifested to the user terminal.By way of non-limiting example, this may include entering informationregarding meetings or other oral conversations, etc.

For each event captured at block 1202, corresponding informationconcerning the event is stored by the user terminal at block 1204. Forexample, in a presently preferred embodiment, such information mayinclude, but is not necessarily limited to, a category of event type, anevent description, the time of the event, the application in which theevent occurred as well as the identity of the user giving rise to theevent. Techniques for generating event information of this type are wellknown in the art. The particular format used for the event informationis a matter of design choice. Likewise, the storage location of theevent information may be a matter of design choice dictated at least inpart by the location at which it is generated. For example, the eventinformation may be stored in a suitable storage device of the userterminal or other local storage device. Alternatively, the eventinformation may be stored within a suitable storage device, such as anetwork server, within the collaboration system itself.

Regardless of the storage location or format of the stored eventinformation, processing continues at block 1206 where an activity reportis generated based on the stored event information. Techniques forgenerating such activity reports (based on the access and mining ofprocess log files of relevant applications to capture the required datafor all events to be included in the activity reports) are well known inthe art. Likewise, the content and format of activity reports are wellknown to those having skill in the art. In a presently preferredembodiment, the information included in the activity reports iscategorized by type, application and time, although other formats areequally possible. As noted previously, the generation of activityreports may occur at virtually any point in time ranging from anon-demand, asynchronous basis to a fully automated, periodic basis. Oncegenerated, an activity report may be provided to a controller forfurther distribution using any of a number of techniques. For example,once generated, an activity report may be stored locally to theprocessing device (e.g., user terminal) that generated it for subsequentprovision to the controller in response to a request or polling by thecontroller. Alternatively, in a “push” embodiment, the activity reportmay be automatically provided to the controller without furtherintervention by the controller.

In parallel with the first path described above, the second pathillustrated in FIG. 12 begins at block 1208 where it is determinedwhether any annotations to an activity report have been provided. Asused herein, an annotation is essentially a content file that istargeted for association with an activity report, as opposed to amessage. As such, annotations may be represented in any of the formatspreviously described and generated in the same manner as content files.In the present context, provision of an annotation may be manifested ina variety of ways. For example, a user interface such as thatillustrated in FIG. 8 may be employed whereby a user manipulates agraphical interface to associate an annotation with an activity report.

Regardless of the manner in which they are provided, processingcontinues at block 1210 where the annotations are submitted forassociation with one or more activity reports. Association of anannotation and an activity report may occur using any of the techniquesdescribed above for associating content files with messages. Forexample, and with reference to FIGS. 9 and 10, where the activity reportis represented in an email format, an annotation may be associated withan activity report as an email attachment. In cases such as this, theannotation is associated with the activity report locally by theprocessing device generating the activity report. Alternatively, theassociation may be accomplished by a remote device, such as acontroller, in the case where the annotation (and any metadata necessaryto establish the association) has been provided directly to thecontroller.

Referring now to FIG. 13, further processing concerning handling ofactivity reports by a controller is described. As noted above, theoperations illustrated in FIG. 13 may be implemented using stored,executable instructions that control operation of one or more suitableprocessors. Beginning at block 1302, the controller receives one or moreactivity reports from user's via their corresponding user terminals. Thecommunication channels described above for use in sending and receivingmessages may be equally employed for this purpose. As noted above, themanner in which the activity reports are received may be in response topolling and/or requests of user terminals made by the controller, orthey may be automatically provided to the controller as in a pushconfiguration. Regardless of the manner in which they are received, thereports may be stored by the controller.

Continuing at block 1304, the controller provides the one or moreactivity reports (using the previously described communication channels)to users of the collaboration system that have been designated toreceive them, either by assignment, choice or both. Processingthereafter optionally continues at either or both of blocks 1306 and1308. At block 1306, one or more annotations may be received by thecontroller and associated with various ones of the activity reports.Annotations may be received from any of the users of the collaborationsystem, including the user that is the subject of a given activityreport, or any of the targeted recipients of the activity report. Tothis end, although block 1306 is illustrated as sequentially occurringafter block 1304, in practice the annotations received at block 1306 mayactually be received (and associated with corresponding activityreports) prior to provision of the activity reports to the designatedusers. Alternatively, such annotations could be received from arecipient of an activity report after the fact as well. In this manner,the activity reports of individual users may serve as a basis forestablishing context around important issues and events. Processing mayalso proceed at block 1308 where the controller aggregates individualactivity reports to provide one or more aggregated activity reports. Anyannotations included with the constituent activity reports included inan aggregated activity report may likewise be associated with theaggregated activity report. Thereafter, at block 1308, any aggregatedactivity reports, or any individual activity reports either notpreviously sent or being sent with recently associated annotations, maybe provided to the designated users at block 1310.

As described above, the present invention provides a collaborationsystem that organizes communication channels between collaboration teammembers, builds context around communications between team members andprovides tools for better developing relationships betweencollaborators. This is achieved through the production of activityreports based on the capture of events defined according a project plan.The ability to further associate annotations with such activity reportsenhances the establishment of context around important issues. Furtherstill, aggregation of activity reports provides context around entiregroups of individuals. In this manner, the present invention overcomesmany of the shortcomings found in the prior art.

While the particular preferred embodiments of the present invention havebeen shown and described, various changes and modifications may be madewithout departing from the teachings of the invention. For example,activity report generation may be distributed, i.e., the user terminalsmay provide the stored event information to the controller, whichperforms activity report generation. It is therefore contemplated thatthe present invention cover any and all modifications, variations orequivalents that fall within the scope of the basic underlyingprinciples disclosed above and claimed herein.

1. In a user terminal for use in a project collaboration system, amethod for reporting activity of a user of the project collaborationsystem, the method comprising: capturing occurrence of at least oneevent caused by the user within the project collaboration system, eachevent of the at least one event defined in accordance with a projectplan; storing information regarding the occurrence of the at least oneevent to provide stored event information; and from time to time,producing an activity report, based at least in part upon the storedevent information, for provision to at least one other user of theproject collaboration system.
 2. The method of claim 1, whereinproducing the activity report is performed on a daily basis.
 3. Themethod of claim 1, wherein capturing occurrence of the at least oneevent further comprises capturing occurrence of at least one task beingmarked as complete.
 4. The method of claim 1, wherein capturingoccurrence of the at least one event further comprises capturingoccurrence of use of an element stored within the project collaborationnetwork.
 5. The method of claim 1, further comprising: receiving reportannotations from the user; and submitting the report annotations forassociation with the activity report.
 6. In a controller operatingwithin a project collaboration system, a method for reporting activityof at least one user of the project collaboration system, the methodcomprising: receiving, from a first user terminal, a first activityreport based on information regarding occurrence of at least one eventcaused by a first user within the project collaboration system, eachevent of the at least one event defined in accordance with a projectplan; and providing the first activity report to at least one other userof the project collaboration system.
 7. The method of claim 6, furthercomprising: receiving, from the first user terminal, report annotations;and associating the report annotations with the first activity report.8. The method of claim 6, further comprising: receiving, from at least asecond user terminal, report annotations responsive to the firstactivity report; and associating the report annotations with the firstactivity report.
 9. The method of claim 6, further comprising: receivinga plurality of activity reports corresponding to a plurality of users ofthe project collaboration system; aggregating the plurality of activityreports to provide an aggregated activity report; and providing theaggregated activity report to the at least one other user.
 10. Anapparatus for use with a project collaboration system, comprising: atleast one processor; and a storage device, in communication with the atleast one processor, having stored thereon executable instructions that,when executed by the at least one processor, cause the at least oneprocessor to: capture occurrence of at least one event caused by theuser within the project collaboration system, each event of the at leastone event defined in accordance with a project plan; store informationregarding the occurrence of the at least one event to provide storedevent information; and from time to time, produce an activity report,based at least in part upon the stored event information, for provisionto at least one other user of the project collaboration system.
 11. Theapparatus of claim 10, wherein the executable instructions that, whenexecuted by the at least one processor, cause the at least one processorto produce the activity report are further operative to produce theactivity report on a daily basis.
 12. The apparatus of claim 10, whereinthe executable instructions that, when executed by the at least oneprocessor, cause the at least one processor to capture occurrence of theat least one event are further operative to capture occurrence of atleast one task being marked as complete.
 13. The apparatus of claim 10,wherein the executable instructions that, when executed by the at leastone processor, cause the at least one processor to capture occurrence ofthe at least one event are further operative to capture occurrence ofuse of an element stored within the project collaboration network. 14.The apparatus of claim 10, wherein the storage device further comprisesexecutable instructions that, when executed by the at least oneprocessor, cause the at least one processor to: receive reportannotations from the user; and submit the report annotations forassociation with the activity report.
 15. An apparatus for use with aproject collaboration system, comprising: at least one processor; and astorage device, in communication with the at least one processor, havingstored thereon executable instructions that, when executed by the atleast one processor, cause the at least one processor to: receive, froma first user terminal, a first activity report based on informationregarding occurrence of at least one event caused by a first user withinthe project collaboration system, each event of the at least one eventdefined in accordance with a project plan; and provide the firstactivity report to at least one other user of the project collaborationsystem.
 16. The apparatus of claim 15, wherein the storage devicefurther comprises executable instructions that, when executed by the atleast one processor, cause the at least one processor to: receive, fromthe first user terminal, report annotations; and associate the reportannotations with the first activity report.
 17. The apparatus of claim15, wherein the storage device further comprises executable instructionsthat, when executed by the at least one processor, cause the at leastone processor to: receive, from at least a second user terminal, reportannotations responsive to the activity report; and associate the reportannotations with the activity report.
 18. The apparatus of claim 15,wherein the storage device further comprises executable instructionsthat, when executed by the at least one processor, cause the at leastone processor to: receive a plurality of activity reports correspondingto a plurality of users of the project collaboration system; aggregatethe plurality of activity reports to provide an aggregated activityreport; and provide the aggregated activity report to the at least oneother user.